r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

inplace_partition personally sounds like a better name to me than partition_mut.

These are inspired by C++ partition and is_partitioned, spurred by this question about mimicking #include <algorithm>.

This requires a DoubleEndedIterator so we can search from front and back for items that need swapping.

Implementation note: C++ allows partition with only ForwardIt, but they have to use two mutable iterators (cursors) to implement it, which Rust can't really allow. The best I could imagine is keeping a queue of &mut T we've already seen, eligible for swapping, which would require allocation (non-core) and seems generally distasteful.

C++ does talk about bi-directional modes too, which I imagine would work like what I have here.

@Mark-Simulacrum

inplace_partition personally sounds like a better name to me than partition_mut.

I'm open to renaming. I don't think an inplace_ prefix is used anywhere else, but there are examples of ptr::drop_in_place and Alloc::grow_in_place and shrink_in_place.

Ah -- in that case I think partition_in_place is probably the better name. I thought we had something similar :) I think the _mut suffix is a bit odd, since the iterator must be &mut to even be able to call the method.

I would have used partition alone if it didn't exist! 🙂 Ours is similar to C++'s partition_copy.

There's also itertools::partition() -- at a (too-brief) glance I had assumed it was just an IntoIterator wrapper on Iterator::partition, like many of their other free functions, but it actually does the same as my partition_mut, in-place. They return the usize index of the partition split, which seems useful.

I wonder if we might also want an index from is_partitioned, or another method along these lines like find_partition(pred) -> Option<usize>. C++ has partition_point returning an iterator, but we can approximate that already with skip_while(predicate).

_in_place does seem like the better naming.

I would have used partition alone if it didn't exist! 🙂 Ours is similar to C++'s partition_copy.

(That wouldn't have been very appropriate imo as our naming is primarily Haskell based...)

OK, that's 3 votes for partition_in_place -- changed!

This looks great to me, thanks @cuviper! Could a few more tests be included as well beyond the doc tests?

Otherwise API-wise would it be feasible to return a usize from partition_in_place to indicate the size of one of the partitions? That way for array indexing you could easily split at the index aftewards in theory

Thanks for the review -- sorry I didn't get back to this yet. I can definitely add more tests, and I think partition_in_place -> usize should be feasible too.

OK, ready for another review.

Looks great to me, thanks @cuviper! r=me with the tracking issue numbers filled in

Done!

@bors r=alexcrichton

📌 Commit 7171c83 has been approved by alexcrichton

⌛ Testing commit 7171c83 with merge 0324a2b...